System and method for dynamic fob synchronization and personalization

ABSTRACT

A system generally for personalizing and synchronizing fob data in the context of a distributed transaction system is disclosed. A dynamic fob synchronization system may comprise point of service (POS) devices configured with transponder-readers to initiate a transaction in conjunction with a fob, an enterprise data collection unit, and a fob object database update system. In an exemplary embodiment, a dynamic synchronization system (DSS) may comprise a personalization system and an account maintenance system configured to communicate with a fob object database update system (FODUS). Personalization of multi-function fobs may be accomplished using a security server configured to generate and/or retrieve cryptographic key information from multiple enterprise key systems during the final phase of the fob issuance process.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a divisional of, and claims priority to, U.S. patentapplication Ser. No. 12/816,311, filed Jun. 15, 2010, entitled “A SYSTEMAND METHOD FOR DYNAMIC FOB SYNCHRONIZATION AND PERSONALIZATION.” The'311 application is a continuation of, and claims priority to, U.S. Pat.No. 7,762,457 issued Jul. 27, 2010 (aka U.S. patent application Ser. No.10/710,570, filed Jul. 21, 2004), entitled “A SYSTEM AND METHOD FORDYNAMIC FOB SYNCHRONIZATION AND PERSONALIZATION.” The '570 applicationis a continuation-in-part of U.S. patent application Ser. No.10/340,352, filed on Jan. 10, 2003, and entitled “SYSTEM AND METHOD FORINCENTING PAYMENT USING RADIO FREQUENCY IDENTIFICATION IN CONTACT ANDCONTACTLESS TRANSACTIONS.” The '352 application itself claims priorityto U.S. Pat. No. 7,239,226, issued on Jul. 3, 2007, and entitled “SYSTEMAND METHOD FOR PAYMENT USING RADIO FREQUENCY IDENTIFICATION IN CONTACTAND CONTACTLESS TRANSACTIONS,” (aka U.S. patent application Ser. No.10/192,488, filed on Jul. 9, 2002) (which itself claims priority to U.S.Provisional No. 60/304,216, filed on Jul. 10, 2001); U.S. patentapplication Ser. No. 10/318,432, entitled “SYSTEM AND METHOD FORSELECTING LOAD OPTIONS FOR USE IN RADIO FREQUENCY IDENTIFICATION INCONTACT AND CONTACTLESS TRANSACTIONS,” filed Dec. 13, 2002; U.S. Pat.No. 7,249,112, issued on Jul. 24, 2007, entitled “SYSTEM AND METHOD FORPAYMENT USING RADIO FREQUENCY IDENTIFICATION IN CONTACT AND CONTACTLESSTRANSACTIONS,” (aka U.S. patent application Ser. No. 10/318,480, filedDec. 13, 2002); and, U.S. Provisional Patent Application No. 60/396,577,filed Jul. 16, 2002. All of the above applications are herebyincorporated by reference.

TECHNICAL FIELD

The present disclosure relates generally to the use of Radio FrequencyIdentification (RFID) in contactless environments for commercialtransactions and, more particularly, to a method and system tofacilitate dynamic synchronization and personalization of fobinformation in the context of a distributed transaction system.

BACKGROUND ART AND TECHNICAL PROBLEMS

Like barcode and voice data entry, RFID is a contactless informationacquisition technology. RFID systems are wireless, and are usuallyextremely effective in hostile environments where conventionalacquisition methods fail. RFID has established itself in a wide range ofmarkets, such as, for example, the high-speed reading of railwaycontainers, tracking moving objects such as livestock or automobiles,and retail inventory applications. As such, RFID technology has become aprimary focus in automated data collection, identification and analysissystems worldwide.

Of late, companies are increasingly embodying RFID data acquisitiontechnology in a fob or tag for use in completing financial transactions.A typical fob may include a transponder and is ordinarily aself-contained device which may be contained on any portable formfactor. In some instances, a battery may be included with the fob topower the transponder, in which case the internal circuitry of the fob(including the transponder) may draw its operating power from thebattery power source. Alternatively, the fob may exist independent of aninternal power source. In this instance the internal circuitry of thefob (including the transponder) may gain its operating power directlyfrom a RF interrogation signal. U.S. Pat. No. 5,053,774, issued toSchuermann, describes a typical transponder RF interrogation systemwhich may be found in the prior art. The Schuermann patent describes ingeneral the powering technology surrounding conventional transponderstructures. U.S. Pat. No. 4,739,328 discusses a method by which aconventional transponder may respond to a RF interrogation signal. Othertypical modulation techniques which may be used include, for example,ISO/IEC 14443 and the like.

In the conventional fob powering technologies used, the fob is typicallyactivated upon presenting the fob in an interrogation signal. In thisregard, the fob may be activated irrespective of whether the userdesires such activation. Inadvertent presentation of the fob may resultin initiation and completion of an unwanted transaction. Thus, a fobsystem is needed which allows the fob user to control activation of thefob to limit transactions being undesirably completed.

One of the more visible uses of the RFID technology is found in theintroduction of Exxon/Mobil's Speedpass® and Shell's EasyPay® products.These products use transponders placed in a fob or tag which enablesautomatic identification of the user when the fob is presented at aPoint-of-sale (POS) device. Fob identification data is typically passedto a third party server database, where the identification data isreferenced to a customer (e.g., user) credit or debit account. In anexemplary processing method, the server seeks authorization for thetransaction by passing the transaction and account data to anauthorizing entity. Once the server receives authorization, clearance issent to the POS device for completion of the transaction. In this way,the conventional transaction processing method involves an indirect pathwhich causes undue overhead due to the use of the third-party server.

It is desirable to maintain, for each fob held by a consumer, asubstantially accurate history of transaction information andapplications associated with the fob. Presently known systems aretypically inadequate in this regard in that they do not provideefficient and reliable methods for ensuring synchronization betweeninformation stored on the fob and corresponding information stored onone or more external databases. As a result, present systems fail toensure that lost or stolen fobs may be reissued or replaced withup-to-date information.

Moreover, present systems are inadequate in that the systems often donot allow an enterprise, such as a fob corporate partner (for example,Hertz, Hilton and the like) to dynamically add to or otherwise modifythe fob application structure itself. That is, in the context ofmulti-function fobs, it is often infeasible to alter or augment thefob's file structure without engaging in the time-consuming and costlyprocess of re-issuing the fob.

Furthermore, known methods of issuing and re-issuing fobs in amulti-application, multi-enterprise environment are typicallyinadequate. More particularly, a fob often contains a number ofdifferent applications associated with a wide range of enterpriseorganizations. For security purposes, the writing, updating, and readingof these files is advantageously restricted to particular parties inaccordance with a set of access condition rules. These access conditionsmay be suitably implemented using cryptographic keys which are knownonly to the appropriate parties, such as the enterprise. Thus, a fobissuing party such as American Express will typically not have access tothe keys to perform its function. Some of the known systems haveattempted to solve this problem by accumulating key data in a centralrepository used in the issuance process. This method is oftenunsatisfactory in a number of respects. Most notably, a security breachin the central repository of key information may have disastrousconsequences.

Techniques are therefore needed to overcome these and other limitationsof the prior art. More specifically, systems are needed to providesecure and efficient personalization and dynamic synchronization ofmulti-function fobs.

SUMMARY OF THE INVENTION

The present invention overcomes the limitations of the prior art byproviding a system and method for personalizing and synchronizing fobdata in the context of a distributed transaction system.

In accordance with one aspect of the present invention, a dynamic fobsynchronization system may comprise POS devices configured to initiate atransaction in conjunction with a fob, an enterprise data collectionunit, and a fob object database update system. An exemplary dynamicsynchronization system (DSS) may comprise various fob POS devices asecure support client server, a fob object database update system(FODUS), one or more enterprise data synchronization interfaces (EDSIs),an update logic system, one or more enterprise data collection units(EDCUs), and one or more point-of-sale (POS) devices configured tointeroperably accept and interface with fobs. In an exemplaryembodiment, DSS may comprise a personalization system and an accountmaintenance system configured to communicate with FODUS.

In accordance with a further aspect of the present invention,personalization of multi-function fobs is accomplished using a securityserver configured to generate and/or retrieve cryptographic keyinformation from multiple enterprise key systems during the final phaseof the fob issuance process.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, wherein like numerals depict like elements,illustrate exemplary embodiments of the present invention, and togetherwith the description, serve to explain the principles of the invention.In the drawings:

FIG. 1 illustrates an exemplary RFID-based system in accordance with thepresent invention, wherein exemplary components used for fob transactioncompletion are depicted;

FIG. 2 is a schematic illustration of an exemplary fob in accordancewith the present invention;

FIG. 3 is a schematic illustration of an exemplary RFID reader inaccordance with the present invention;

FIG. 4 is an exemplary flow diagram of an exemplary authenticationprocess in accordance with the present invention;

FIG. 5 is an exemplary flow diagram of an exemplary decision process fora protocol/sequence controller in accordance with the present invention;

FIG. 6 is an example of a conventional magnetic stripe track 2 layoutfor MasterCard;

FIG. 7 is an exemplary transaction data structure suitable for use in atravel context;

FIG. 8 is a flow diagram of an exemplary payment/transaction process inaccordance with the present invention;

FIG. 9 is another schematic illustration of an exemplary fob inaccordance with the present invention;

FIG. 10 is a schematic overview of an exemplary dynamic synchronizationsystem in accordance with various aspects of the present invention;

FIG. 11 is a schematic overview of an exemplary secure support clientserver;

FIG. 12 is a schematic overview of an exemplary enterprise datasynchronization interface;

FIG. 13 is a schematic overview of an exemplary update logic system;

FIG. 14 is a schematic overview of an exemplary enterprise datacollection unit;

FIG. 15 is a schematic overview of an exemplary fob object databaseupdate system (FODUS);

FIG. 16 is a flowchart depicting an exemplary method for synchronizingpending transaction information;

FIG. 17 is a flowchart depicting an exemplary method for synchronizingupdate transaction information;

FIG. 18 is a schematic overview of an exemplary personalization system;and

FIG. 19 is a flowchart depicting an exemplary method of fobpersonalization.

DETAILED DESCRIPTION OF PREFERRED EXEMPLARY EMBODIMENTS

The present invention may be described herein in terms of functionalblock components, screen shots, optional selections and variousprocessing steps. Such functional blocks may be realized by any numberof hardware and/or software components configured to perform specifiedfunctions. For example, the present invention may employ variousintegrated circuit components (e.g., memory elements, processingelements, logic elements, look-up tables, and the like), which may carryout a variety of functions under the control of one or moremicroprocessors or other control devices. Similarly, the softwareelements of the present invention may be implemented with anyprogramming or scripting language such as C, C++, Java, COBOL,assembler, PERL, extensible markup language (XML), JavaFob and MULTOSwith the various algorithms being implemented with any combination ofdata structures, objects, processes, routines or other programmingelements. Further, it should be noted that the present invention mayemploy any number of conventional techniques for data transmission,signaling, data processing, network control, and the like. For a basicintroduction on cryptography, review a text written by Bruce Schneierentitled “Applied Cryptography: Protocols, Algorithms, and Source Codein C,” published by John Wiley & Sons (second edition, 1996), hereinincorporated by reference.

In addition, many applications of the present invention could beformulated. The exemplary network disclosed herein may include anysystem for exchanging data or transacting business, such as theInternet, an intranet, an extranet, WAN, LAN, satellite communications,and/or the like. It may be noted that the network may be implemented asother types of networks, such as an interactive television network(ITN).

Where required, the system user may interact with the system via anyinput device such as, a keypad, keyboard, mouse, kiosk, personal digitalassistant, handheld computer (e.g., Palm Pilot®, Blueberry®), cellularphone and/or the like. Similarly, the invention could be used inconjunction with any type of personal computer, network computer, workstation, minicomputer, mainframe, or the like running any operatingsystem such as any version of Windows, Windows NT, Windows 2000, Windows98, Windows 95, MacOS, OS/2, BeOS, Linux, UNIX, Solaris or the like.Moreover, although the invention may frequently be described as beingimplemented with TCP/IP communications protocol, it should be understoodthat the invention could also be implemented using SNA, IPX, Appletalk,IPte, NetBIOS, OSI or any number of communications protocols. Moreover,the system contemplates, the use, sale, or distribution of any goods,services or information over any network having similar functionalitydescribed herein.

FIG. 1 illustrates an exemplary RFID transaction system 100 inaccordance with the present invention, wherein exemplary components foruse in completing a fob transaction using travel-related information aredepicted. In general, the operation of system 100 may begin when fob 102may be presented for payment, and may be interrogated by RFID reader 104or, alternatively, interface 134. Fob 102 and RFID reader 104 may thenengage in mutual authentication after which the fob 102 may provide thetransponder identification, account identifier and/or travel-relatedinformation to the RFID reader 104 which may further provide theinformation to the merchant system 130 POS device 110.

System 100 may include a fob 102 having a transponder 114 and a RFIDreader 104 in RF communication with fob 102. Although the presentinvention may be described with respect to a fob 102, the invention maybe not to be so limited. Indeed, system 100 may include any devicehaving a transponder which may be configured to communicate with a RFIDreader 104 via RF communication. Typical devices may include, forexample, a key ring, tag, fob, cell phone, wristwatch or any such formcapable of being presented for interrogation.

RFID reader 104 may be configured to communicate using a RFID internalantenna 106. Alternatively, RFID reader 104 may include an externalantenna 108 for communications with fob 102, where the external antennamay be made remote to RFID reader 104 using a suitable cable and/or datalink 120. RFID reader 104 may be further in communication with amerchant system 130 via a data link 122. System 100 may include atransaction completion system including a point of interaction devicesuch as, for example, a merchant point-of-sale (POS) device 110 or acomputer interface (e.g., user interface) 134. In one exemplaryembodiment the transaction completion system may include a merchantsystem 130 including POS device 110 in communication with RFID reader104 (via data link 122). As described more fully below, the transactioncompletion system may include user interface 134 connected to a network136 and to the transponder via a USB connector 132.

Although the point of interaction device may be described herein withrespect to a merchant point-of-sale (POS) device, the invention may benot to be so limited. Indeed, a merchant POS device may be used hereinby way of example, and the point of interaction device may be any devicecapable of receiving fob account data. In this regard, the POS may beany point of interaction device enabling the user to complete atransaction using fob 102. POS device 110 may be in furthercommunication with a customer interface 118 (via data link 128) forentering customer identity verification information. In addition, POSdevice 110 may be in communication with merchant host network 112 (viadata link 124), an issuer host network, and/or any other access pointfor processing any transaction request. In this arrangement, informationprovided by RFID reader 104 may be provided to POS device 110 ofmerchant system 130 via data link 122. POS device 110 may receive theinformation (and alternatively may receive any identity verifyinginformation from customer interface 118 via data link 128) and providethe information to host system 112 for processing.

A variety of conventional communications media and protocols may be usedfor data links 120, 122, 124, and 128. For example, data links 120, 122,124, and 128 may be an Internet Service Provider (ISP) configured tofacilitate communications over a local loop as may be typically used inconnection with standard modem communication, cable modem, dishnetworks, ISDN, Digital Subscriber Lines (DSL), or any wirelesscommunication media. In addition, the merchant system 130 including POSdevice 110 and host network 112 may reside on a local area network whichinterfaces to a remote network (not shown) for remote authorization ofan intended transaction. The merchant system 130 may communicate withthe remote network via a leased line, such as a T1, D3 line, or thelike. Such communications lines are described in a variety of texts,such as, “Understanding Data Communications,” by Gilbert Held, which maybe incorporated herein by reference.

An account number, as used herein, may include any identifier for anaccount (e.g., credit, charge debit, checking, savings, reward, loyalty,travel or the like) which may be maintained by a transaction accountprovider (e.g., payment authorization center) and which may be used tocomplete a financial transaction. A typical account number (e.g.,account data) may be correlated to a credit or debit account, loyaltyaccount, travel or rewards account maintained and serviced by suchentities as American Express, Visa and/or MasterCard, or the like. Forease in understanding, the present invention may be described withrespect to a credit card account. However, it should be noted that theinvention may be not so limited and other accounts permitting anexchange of goods and services for an account data value may becontemplated to be within the scope of the present invention.

In addition, the account number (e.g., account data) may be associatedwith any device, code, or other identifier/indicia suitably configuredto allow the consumer to interact or communicate with the system, suchas, for example, authorization/access code, personal identificationnumber (PIN), Internet code, digital certificate, biometric data, and/orother identification indicia. The account number may be optionallylocated on a rewards card, charge card, credit card, debit card, prepaidcard, telephone card, smart card, magnetic stripe card, bar code card,and/or the like. The account number may be distributed and stored in anyform of plastic, electronic, magnetic, and/or optical device capable oftransmitting or downloading data to a second device. A customer accountnumber may be, for example, a sixteen-digit credit card number, althougheach credit provider has its own numbering system, such as thefifteen-digit numbering system used by American Express. Each company'scredit card numbers comply with that company's standardized format suchthat the company using a sixteen-digit format will generally use fourspaced sets of numbers, as represented by the number “0000 0000 00000000”. In a typical example, the first five to seven digits are reservedfor processing purposes and identify the issuing bank, card type andetc. In this example, the last sixteenth digit may be used as a sumcheck for the sixteen-digit number. The intermediary eight-to-ten digitsare used to uniquely identify the customer. The account number stored asTrack 1 and Track 2 data as defined in ISO/IEC 7813, and further may bemade unique to fob 102. Track 1 and Track 2 data may be described inmore detail below. In one exemplary embodiment, the account number mayinclude a unique fob serial number and user identification number, aswell as specific application applets. The account number may be storedin fob 102 inside a database 214, as described more fully below.Database 214 may be configured to store multiple account numbers issuedto fob 102 user by the same or different account providing institutions.Where the account data corresponds to a loyalty or rewards account,database 214 may be configured to store the attendant loyalty or rewardspoints data.

FIG. 2 illustrates a block diagram of the many functional blocks ofexemplary fob 102 in accordance with the present invention. Fob 102 maybe an RFID fob 102 which may be presented by the user to facilitate anexchange of funds or points, etc., for receipt of goods or services. Asdescribed herein, by way of example, fob 102 may be an RFID fob whichmay be presented for facilitating payment for goods and/or services.

Fob 102 may include an antenna 202 for receiving an interrogation signalfrom RFID reader 104 via antenna 106 (or alternatively, via externalantenna 108). Fob antenna 202 may be in communication with a transponder114. In one exemplary embodiment, transponder 114 may be a 13.56 MHztransponder compliant with the ISO/IEC 14443 standard, and antenna 202may be of the 13 MHz variety. Transponder 114 may be in communicationwith a transponder compatible modulator/demodulator 206 configured toreceive the signal from transponder 114 and configured to modulate thesignal into a format readable by any later connected circuitry. Further,modulator/demodulator 206 may be configured to format (e.g., demodulate)a signal received from the later connected circuitry in a formatcompatible with transponder 114 for transmitting to RFID reader 104 viaantenna 202. For example, where transponder 114 may be of the 13.56 MHzvariety, modulator/demodulator 206 may be ISO/IEC 14443-2 compliant.

Modulator/demodulator 206 may be coupled to a protocol/sequencecontroller 208 for facilitating control of the authentication of thesignal provided by RFID reader 104, and for facilitating control of thesending of fob 102 account number. In this regard, protocol/sequencecontroller 208 may be any suitable digital or logic driven circuitrycapable of facilitating determination of the sequence of operation forfob 102 inner-circuitry. For example, protocol/sequence controller 208may be configured to determine whether the signal provided by RFIDreader 104 may be authenticated, and thereby providing to RFID reader104 the account number stored on fob 102.

Protocol/sequence controller 208 may be further in communication withauthentication circuitry 210 for facilitating authentication of thesignal provided by RFID reader 104. Authentication circuitry may befurther in communication with a non-volatile secure memory database 212.Secure memory database 212 may be any suitable elementary file systemsuch as that defined by ISO/IEC 7816-4 or any other elementary filesystem allowing a lookup of data to be interpreted by the application onthe chip. Database 212 may be any type of database, such as relational,hierarchical, object-oriented, and/or the like. Common database productsthat may be used to implement the databases include DB2 by IBM (WhitePlains, N.Y.), any of the database products available from OracleCorporation (Redwood Shores, Calif.), Microsoft Access or MSSQL byMicrosoft Corporation (Redmond, Wash.), or any other database product.Database may be organized in any suitable manner, including as datatables or lookup tables. Association of certain data may be accomplishedthrough any data association technique known and practiced in the art.For example, the association may be accomplished either manually orautomatically. Automatic association techniques may include, forexample, a database search, a database merge, GREP, AGREP, SQL, and/orthe like. The association step may be accomplished by a database mergefunction, for example, using a “key field” in each of the manufacturerand retailer data tables. A “key field” partitions the databaseaccording to the high-level class of objects defined by the key field.For example, a certain class may be designated as a key field in boththe first data table and the second data table, and the two data tablesmay then be merged on the basis of the class data in the key field. Inthis embodiment, the data corresponding to the key field in each of themerged data tables may be, in one embodiment, the same. However, datatables having similar, though not identical, data in the key fields mayalso be merged by using AGREP, for example.

The data may be used by protocol/sequence controller 208 for dataanalysis and used for management and control purposes, as well assecurity purposes. Authentication circuitry may authenticate the signalprovided by RFID reader 104 by association of the RFID signal toauthentication keys stored on database 212. Encryption circuitry may usekeys stored on database 212 to perform encryption and/or decryption ofsignals sent to or from RFID reader 104.

In addition, protocol/sequence controller 208 may be in communicationwith a database 214 for storing at least fob 102 account data, and aunique fob 102 identification code. Protocol/sequence controller 208 maybe configured to retrieve the account number from database 214 asdesired. Database 214 may be of the same configuration as database 212described above. The fob account data and/or unique fob identificationcode stored on database 214 may be encrypted prior to storage. Thus,where protocol/sequence controller 208 retrieves the account data, andor unique fob identification code from database 214, the account numbermay be encrypted when being provided to RFID reader 104. Further, thedata stored on database 214 may include, for example, an unencryptedunique fob 102 identification code, a user identification, Track 1 and 2data, as well as specific application applets.

In accordance with another exemplary embodiment, the account number maybe stored in magnetic stripe format. For example, where the accountnumber may be in magnetic stripe format, the International StandardsOrganization ISO/IEC 7811, et al. standard, governs the account numberportions which are hereby incorporated by reference. The standardrequires the magnetic stripe information to be encoded in three “tracks”(i.e., track 1, track 2, and track 3).

Data stored in track 1 may be typically used to verify the user'sidentity. Track 1 may be reserved for encoding the transaction accountidentifier, the name of the accountholder, and at least the expirationdate of the transaction account or the transaction device. Theinformation encoded in track 1 may be alpha-numeric and may be encodedat about 7 Bits/Character. In an exemplary layout of the data stored intrack 1, track 1 may be segmented into several distinct predeterminedportions (e.g., “fields”) for encoding the various account identifyinginformation. The following table may be useful for determining the fielddefinitions of the information provided.

TABLE 1 Table of Field Codes for Track 1 SS = Start Sentinel “%” FC =Format Code PAN = Primary Acct. # (19 digits max) FS = Field Separator“{circumflex over ( )}” Name = 26 alphanumeric characters max.Additional Data = Expiration Date, offset, encrypted PIN, etc. ES = EndSentinel “?” LRC = Longitudinal Redundancy Check

Track 2 may be the track most commonly used by the American BankingAssociation associated banking institutions. Track 2 may be typicallyreserved for a duplicate version of the transaction account identifierand the expiration date of the transaction account or the transactiondevice stored in track 1. In addition, track 2 may include an encryptedPersonal Identification Code, and other discretionary data. However, thedata in track 2 may be encoded at a lower Bit per Character density thanthe data encoded in track 1. The data in track 2 may be numeric only andmay be encoded at about 5 Bits/Character. The lower density ratio intrack 2 may be designed to ensure compatibility with older technologyreaders and to provide redundancy when reading with newer technologyreaders. FIG. 8 illustrates an exemplary layout of the data stored intrack 2, wherein track 2 may be segmented into several distinctpredetermined portions for encoding the various account identifyinginformation. As shown, the following table may be useful for determiningthe definitions of the information provided.

TABLE 2 Table of Field Codes for Track 2 SS = Start Sentinel “%” SS =Start Sentinel “;” PAN = Primary Acct. # (19 digits max) FS = FieldSeparator “=” Additional Data = Expiration Date, offset, encrypted PIN,etc. ES = End Sentinel “?” LRC = Longitudinal Redundancy Check

Track 3 may be of similar description as Track 2. With the InternationalStandards Organization adoption of standard ISO/IEC 4909, track 3 of themagnetic stripe format was no longer used by the banking industry.However, other transaction devices including a magnetic stripe, such asdrivers licenses, use track 3, which may include both numeric only andalpha numeric characters. Track 3 may be unique in that track 3 wasintended to have data read and WRITTEN on it. Fob users may have accountinformation UPDATED right on the magnetic stripe. The present inventionanticipates that a fob user's travel-related information profile and/oraccount information may be updated using track 3. Unfortunately, track 3may be almost an orphaned standard, since most readers currently inoperation are not configured to write data onto a magnetic stripe. Theoriginal design of track 3 was to control off-line ATM transactions byrecording transaction data for later reference by the bankinginstitution. But since ATMs are now on-line, the usage of track 3 hasbeen drastically reduced.

The most common technique used to encode data in magnetic stripe formatmay be known as Aiken Biphase, or “two-frequency coherent-phaseencoding.” The American National Standards Institute (ANSI) and theInternational Standards Organization (ISO) have chosen two standards toguide the encoding process. The ISO encoding protocol specifies thateach of tracks 1, 2 and 3 must begin and end with a length of all Zerobits, called CLOCKING BITS. These are used to synch the self-clockingfeature of bi-phase decoding. In addition, most transaction deviceswhich use magnetic stripe encoding protocol use either the ANSI/ISOALPHA Data format or the ANSI/ISO BCD Data format. For example, track 1may be typically encoded in ANSI/ISO ALPHA Data format which may be a 7bit, 6 data bits+1 parity bit (odd) format, where the data may be readleast significant bit first. The ANSI/ISO ALPHA format character setcontains 64 characters, 43 alphanumeric, 3 framing/field characters and18 control/special characters. On the other hand, tracks 2 and 3 aretypically encoded in ANSI/ISO BCD Data format, which may be a 5 bit, 4data bits+1 parity bit (odd) format. The character set for the ANSI/ISOBCD Data format character set contains 16 characters, 10 alphanumeric, 3framing/field characters and 3 control/special characters.

Ordinarily, a proxy account number (e.g., a portion of the transactionaccount number) includes essential identifying information, such as, forexample, any information that may be common to the account provider. Thecommon information (also called “common character,” herein) may includethe account provider routing number, or common source indicator such asthe character spaces reserved to indicate the identification of theissuing bank. Thus, where the proxy transaction account identifiercorresponds to an American Express account, the proxy transactionaccount identifier may include the common character number 3, encodedthe field location where such common character may be ordinarily encodedin traditional magnetic stripe format.

FIG. 6 illustrates the encoding of which may ordinarily be done by anentity, such as, for example, MasterCard in track 2 format. FIG. 6 showsthe encoding of a MasterCard account number 3111 2222 3333 4444 withexpiration date 12/99 in traditional track 1 format. Since MasterCarduses the number 3 to identify its transaction accounts, the proxyaccount identifier will also use the number 3 so that the receivingsystem (e.g., reader 104 or merchant system 130, or account provider)further recognizes that the proxy account identifier may be from aMasterCard transaction device. It should be noted that in this example,the “3” and the “101” may be common characters to all MasterCardtransaction accounts. For a more detailed explanation of magnetic stripeformat data exchange, see U.S. patent application Ser. No. 10/810,473,filed on Mar. 26, 2004, entitled “SYSTEM AND METHOD FOR ENCODINGINFORMATION IN MAGNETIC STRIPE FORMAT FOR USE IN RADIO FREQUENCYIDENTIFICATION TRANSACTIONS,” incorporated herein by reference.

Fob 102 may be configured to respond to multiple interrogation frequencytransmissions provided by RFID reader 104. That may be, as describedmore fully below, RFID reader 104 may provide more than one RFinterrogation signal. In this case, fob 102 may be configured to respondto the multiple frequencies by including in fob 102 one or moreadditional RF signal receiving/transmitting units 226. RF signalreceiving/transmitting unit 226 may include an antenna 218 andtransponder 220 where the antenna 218 and transponder 220 are compatiblewith at least one of the additional RF signals provided by RFID reader104. For example, in one exemplary embodiment, fob 102 may include a 134kHz antenna 218 configured to communicate with a 134 kHz transponder220. In this exemplary configuration, an ISO/IEC 14443-2 compliantmodulator/demodulator may not be required. Instead, the 134 kHztransponder may be configured to communicate directly with theprotocol/sequence controller 208 for transmission and receipt ofauthentication and account number signals as described above.

In another embodiment, fob 102 may further include a universal serialbus (USB) connector 132 for interfacing fob 102 to a user interface 134.User interface 134 may be further in communication with a POS device 110via a network 136. Network 136 may be the Internet, an intranet, or thelike as may be described above with respect to network 112. Further,user interface 134 may be similar in construction to any conventionalinput devices and/or computing systems aforementioned for permitting thesystem user to interact with the system. In one exemplary embodiment,fob 102 may be configured to facilitate online Internet payments. A USBconverter 222 may be in communication with a USB connector 132 forfacilitating the transfer of information between themodulator/demodulator 206 and USB connector 132. Alternatively, USBconverter 222 may be in communication with protocol/sequence controller208 to facilitate the transfer of information between protocol/sequencecontroller 208 and USB connector 132.

Where fob 102 includes a USB connector 132, fob 102 may be incommunication with, for example, a USB port on user interface 134. Theinformation retrieved from fob 102 may be compatible with credit cardand/or smart card technology enabling usage of interactive applicationson the Internet. No RFID reader may be required in this embodiment sincethe connection to POS device 110 may be made using a USB port on userinterface 134 and a network 136.

Fob 102 may include means for enabling activation of the fob by theuser. In one exemplary embodiment, a switch 230 which may be operated bythe user of fob 102. The switch 230 on fob 102 may be used toselectively or inclusively activate fob 102 for particular uses. In thiscontext, the term “selectively” may mean that the switch 230 enables theuser to place fob 102 in a particular operational mode. For example, theuser may place fob 102 in a mode for enabling purchase of a good or of aservice using a selected account number. Alternatively, the fob may beplaced in a mode as such that the fob account number may be provided byUSB port 132 (or serial port) only and the fob transponder 114 may bedisabled. In addition, the term “inclusively” may mean that fob 102 maybe placed in an operational mode permitting fob 102 to be responsive tothe RF interrogation and interrogation via the USB connector 132. In oneparticular embodiment, the switch 230 may remain in an OFF positionensuring that one or more applications or accounts associated with fob102 are non-reactive to any commands issued by RFID reader 104. As usedherein, the OFF position may be termed the “normal” position of theactivation switch 230, although other normal positions are contemplated.

In another exemplary embodiment, when the switch 230 may be moved fromthe OFF position, fob 102 may be deemed activated by the user. That maybe, the switch 230 may activate internal circuitry in fob 102 forpermitting the fob to be responsive to RF signals (e.g., commands fromRFID reader 104). In this way, switch 230 may facilitate control of theactive and inactive states of fob 102. Such control increases the systemsecurity by preventing inadvertent or illegal use of fob 102.

In one exemplary embodiment, switch 230 may be a simple mechanicaldevice in communication with circuitry which may electrically preventthe fob from being powered by a RFID reader. That may be, when switch230 may be in its normal position, switch 230 may provide a short to fob102 internal circuitry, preventing fob 102 from being responsive tointerrogation by RF or via the USB connector 230. In this arrangement,the switch 230 may be, for example, a “normally closed” (NC) configuredswitch, which may be electrically connected to the antenna 202 at theinterface of the antenna 202 and the transponder 114. The switch 230 maybe depressed, which may open the switch 230 fully activating the antenna202.

In yet another exemplary embodiment, fob 102 may include a biometricsensor and biometric membrane configured to operate as switch 230 andactivate fob 102 when provided biometric signal from fob 102 user. Suchbiometric signal may be the digital reading of a fingerprint,thumbprint, or the like. Typically, where biometric circuitry may beused, the biometric circuitry may be powered by an internal voltagesource (e.g., battery). In this case, the switch may not be a simplemechanical device, but a switch which may be powered. In yet anotherexemplary embodiment, switch 230 may be battery powered though nobiometric circuitry may be present in fob 102.

In yet another embodiment, the switch 230 may be a logic switch. Whereswitch 230 may be a logic switch the switch 230 control software may beread from the sequence controller 208 to selectively control theactivation of the various fob 102 components.

FIG. 3 illustrates an exemplary block diagram of RFID reader 104 inaccordance with an exemplary embodiment of the present invention. RFIDreader 104 includes, for example, an antenna 202 coupled to a RF module302, which may be further coupled to a control module 304. In addition,RFID reader 104 may include an antenna 108 positioned remotely from RFIDreader 104 and coupled to RFID reader 104 via a suitable cable 120, orother wire or wireless connection.

RF module 302 and antenna 202 may be suitably configured to facilitatecommunication with fob 102. Where fob 102 may be formatted to receive asignal at a particular RF frequency, RF module 302 may be configured toprovide an interrogation signal at that same frequency. For example, inone exemplary embodiment, fob 102 may be configured to respond to aninterrogation signal of about 13.56 MHz. In this case, RFID antenna 202may be 13 MHz and may be configured to transmit an interrogation signalof about 13.56 MHz. Fob 102 may be configured to include a first andsecond RF module (e.g., transponder) where the first module may operateusing a 134 kHz frequency and the second RF module may operate using a13.56 MHz frequency. RFID reader 104 may include two receivers which mayoperate using the 134 kHz frequency, the 13.56 MHz frequency or both.When the reader 104 may be operating at 134 kHz frequency, onlyoperation with the 134 kHz module on fob 102 may be possible. When thereader 104 may be operating at the 13.56 MHz frequency, only operationwith the 13.56 MHz module on fob 102 may be possible. Where the reader104 supports both a 134 kHz frequency and a 13.56 MHz RF module, fob 102may receive both signals from the reader 104. In this case, fob 102 maybe configured to prioritize selection of the one or the other frequencyand reject the remaining frequency. Alternatively, the reader 104 mayreceive signals at both frequencies from the fob upon interrogation. Inthis case, the reader 104 may be configured to prioritize selection ofone or the other frequency and reject the remaining frequency.

Further, protocol/sequence controller 314 may include an optionalfeedback function for notifying the user of the status of a particulartransaction. For example, the optional feedback may be in the form of anLED, LED screen and/or other visual display which may be configured tolight up or display a static, scrolling, flashing and/or other messageand/or signal to inform fob 102 user that the transaction may beinitiated (e.g., fob may be being interrogated), the fob may be valid(e.g., fob may be authenticated), transaction may be being processed,(e.g., fob account number may be being read by RFID reader) and/or thetransaction may be accepted or denied (e.g., transaction approved ordisapproved). Such an optional feedback may or may not be accompanied byan audible indicator (or may present the audible indicator singly) forinforming fob 102 user of the transaction status. The audible feedbackmay be a simple tone, multiple tones, musical indicator, and/or voiceindicator configured to signify when fob 102 may be being interrogated,the transaction status, or the like.

RFID antenna 202 may be in communication with a transponder 306 fortransmitting an interrogation signal and receiving at least one of anauthentication request signal and/or an account data from fob 102.Transponder 306 may be of similar description as transponder 114 of FIG.2. In particular, transponder 306 may be configured to send and/orreceive RF signals in a format compatible with antenna 202 in similarmanner as was described with respect to fob transponder 114. Forexample, where transponder 306 may be 13.56 MHz RF rated antenna 202 maybe 13.56 MHz compatible. Similarly, where transponder 306 may be ISO/IEC14443 rated, antenna 202 may be ISO/IEC 14443 compatible.

RF module 302 may include, for example, transponder 306 in communicationwith authentication circuitry 308 which may be in communication with asecure database 310. Authentication circuitry 308 and database 310 maybe of similar description and operation as described with respect toauthentication circuitry 210 and secure memory database 212 of FIG. 2.For example, database 310 may store data corresponding to fob 102 whichare authorized to transact business over system 100. Database 310 mayadditionally store RFID reader 104 identifying information for providingto fob 102 for use in authenticating whether RFID reader 104 may beauthorized to be provided the fob account number stored on fob database214.

Authentication circuitry 308 may be of similar description and operationas authentication circuitry 210. That may be, authentication circuitry308 may be configured to authenticate the signal provided by fob 102 insimilar manner that authentication circuitry 210 may be configured toauthenticate the signal provided by RFID reader 104. As may be describedmore fully below, fob 102 and RFID reader 104 may engage in mutualauthentication. In this context, “mutual authentication” may mean thatoperation of the system 100 may not take place until fob 102authenticates the signal from RFID reader 104, and RFID reader 104authenticates the signal from fob 102.

FIG. 4 may be a flowchart of an exemplary authentication process inaccordance with the present invention. The authentication process may bedepicted as one-sided. The flowchart depicts the process of RFID reader104 authenticating fob 102, although similar steps may be followed inthe instance that fob 102 authenticates RFID reader 104.

As noted, database 212 may store security keys for encrypting ordecrypting signals received from RFID reader 104. In an exemplaryauthentication process, where RFID reader 104 may be authenticating fob102, RFID reader 104 may provide an interrogation signal to fob 102(step 402). The interrogation signal may include a random code generatedby the RFID reader authentication circuit 210, which may be provided tofob 102 and which may be encrypted using a unique encryption keycorresponding to fob 102 unique identification code. For example, theprotocol/sequence controller 314 may provide a command to activate theauthentication circuitry 308. Authentication circuitry 308 may providefrom database 310 a fob interrogation signal including a random numberas a part of the authentication code generated for each authenticationsignal. The authentication code may be an alphanumeric code which may berecognizable (e.g., readable) by RFID reader 104 and fob 102. Theauthentication code may be provided to fob 102 via the RFID RF interface306 and antenna 202 (or alternatively antenna 108).

Fob 102 may receive the interrogation signal (step 404). Theinterrogation signal including the authorization code may be received atthe RF interface 114 via antenna 202. Once fob 102 may be activated, theinterrogation signal, including the authorization code, may be providedto the modulator/demodulator circuit 206 where the signal may bedemodulated prior to providing the signal to protocol/sequencecontroller 208. Protocol/sequence controller 208 may recognize theinterrogation signal as a request for authentication of fob 102, andprovide the authentication code to authentication circuit 210. Fob 102may then encrypt the authentication code (step 406). In particular,encryption may be done by authentication circuit 210, which may receivethe authentication code and encrypt the code prior to providing theencrypted authentication code to protocol/sequence controller 208. Fob102 may then provide the encrypted authentication code to RFID reader104 (step 408). The encrypted authentication code may be provided toRFID reader 104 via modulator/demodulator circuit 206, RF interface 114(e.g., transponder 114) and antenna 202.

RFID reader 104 may then receive the encrypted authentication code anddecrypt it (step 410). The encrypted authentication code may be receivedat antenna 202 and RF interface 306 and may be provided toauthentication circuit 308. Authentication circuit 308 may be provided asecurity authentication key (e.g., transponder system decryption key)from database 310. The authentication circuit may use the authenticationkey to decrypt (e.g., unlock) the encrypted authorization code. Theauthentication key may be provided to the authentication circuit basedon fob 102 unique identification code. For example, the encryptedauthentication code may be provided along with the unique fob 102identification code. The authentication circuit may receive fob 102unique identification code and retrieve from the database 310 atransponder system decryption key correlative to the unique fob 102identification code for use in decrypting the encrypted authenticationcode.

Once the authentication code may be decrypted, the decryptedauthentication code may be compared to the authentication code providedby RFID reader 104 at step 402 (step 412) to verify its authenticity. Ifthe decrypted authorization code is not readable (e.g., recognizable) bythe authentication circuit 308, fob 102 may be deemed to be unauthorized(e.g., unverified) (step 418) and the operation of system 100 may beterminated (step 420). Contrarily, if the decrypted authorization codemay be recognizable (e.g., verified) by fob 102, the decryptedauthorization code may be deemed to be authenticated (step 414), and thetransaction may be allowed to proceed (step 416). In one particularembodiment, the preceding transaction may mean that fob 102 mayauthenticate RFID reader 104, although, it should be apparent that RFIDreader 104 may authenticate fob 102 prior to fob 102 authenticating RFIDreader 104.

It should be noted that in an exemplary verification process, theauthorization circuit 308 may determine whether the unlockedauthorization code may be identical to the authorization code providedin step 402. If the codes are not identical then fob 102 may not beauthorized to access system 100. Although, the verification process maybe described with respect to identicality, identicality may be notrequired. For example, authentication circuit 308 may verify thedecrypted code through any protocol, steps, or process for determiningwhether the decrypted code corresponds to an authorized fob 102.

Authentication circuitry 308 may additionally be in communication with aprotocol/sequence controller 314 of similar operation and description asprotocol/sequence controller 208 of FIG. 2. That may be,protocol/sequence device controller 314 may be configured to determinethe order of operation of RFID reader 104 components. For example, FIG.5 illustrates an exemplary decision process under whichprotocol/sequence controller 314 may operate. Protocol/sequencecontroller 314 may command the different components of RFID reader 104based on whether fob 102 may be present (step 502). For example, if fob102 may not be present, then protocol/sequence controller 314 maycommand RFID reader 104 to provide an uninterrupted interrogation signal(step 504). The protocol/sequence controller may command theauthentication circuit 308 to provide an uninterrupted interrogationsignal until the presence of fob 102 may be realized. If fob 102 may bepresent, the protocol/sequence controller 314 may command RFID reader104 to authenticate fob 102 (step 506).

As noted above, authentication may mean that the protocol/sequencecontroller 314 may command the authentication circuit 308 to provide fob102 with an authorization code. If a response may be received from fob102, protocol/sequence controller may determine if the response may be aresponse to RFID reader 104 provided authentication code, or if theresponse may be a signal requiring authentication (step 508). If thesignal requires authentication, then the protocol/sequence controller314 may activate the authentication circuit as described above (step506). On the other hand, if fob 102 signal may be a response to theprovided authentication code, then the protocol/sequence controller 314may command RFID reader 104 to retrieve the appropriate security key forenabling recognition of the signal (step 510). The protocol/sequencecontroller 314 may command the authentication circuit 308 to retrievefrom database 310 a security key (e.g., transponder system decryptionkey), unlock the signal, and compare the signal to the signal providedby RFID reader 104 in the authentication process (e.g., step 506). Ifthe signal is recognized, the protocol/sequence controller 314 maydetermine that fob 102 may be authorized to access the system 100. Ifthe signal is not recognized, then the fob may be considered notauthorized, in which case, protocol/sequence controller 314 may commandthe RFID controller to interrogate for authorized fobs (step 504).

Once the protocol/sequence controller determines that fob 102 may beauthorized, the protocol/sequence controller 314 may seek to determineif additional signals are being sent by fob 102 (step 514). If noadditional signal may be provided by fob 102, then the protocol/sequencecontroller 314 may provide all the components of RFID reader 104 toremain idle until such time as a signal may be provided (step 516).Contrarily, where an additional fob 102 signal may be provided, theprotocol/sequence controller 314 may determine if fob 102 may berequesting access to the merchant point-of-sale terminal 110 (e.g., POSdevice) or if fob 102 may be attempting to interrogate RFID reader 104for return (e.g., mutual) authorization (step 518). Where fob 102 may berequesting access to a merchant POS device 110, the protocol/sequencecontroller 314 may command the RFID reader to open communications withthe POS device 110 (step 524). In particular, the protocol/sequencecontroller may command the POS device 110 communications interface 312to become active, permitting transfer of data between RFID reader 104and the merchant POS device 110.

On the other hand, if the protocol/sequence controller determines thatfob 102 signal may be a mutual interrogation signal, then theprotocol/sequence controller may command RFID reader 104 to encrypt thesignal (step 520). The protocol/sequence controller 314 may command theencryption authentication circuit 318 to retrieve from database 320 theappropriate encryption key in response to fob 102 mutual interrogationsignal. The protocol/sequence controller 314 may then command RFIDreader 104 to provide the encrypted mutual interrogation signal to fob102. The protocol/sequence controller 314 may command the authenticationcircuit 318 to provide an encrypted mutual interrogation signal for fob102 to mutually authenticate. Fob 102 may then receive the encryptedmutual interrogation signal and retrieve from authentication circuitry212 a RFID reader decryption key.

Although an exemplary decision process of protocol/sequence controller314 may be described, it should be understood that a similar decisionprocess may be undertaken by protocol/sequence controller 208 incontrolling the components of fob 102. Indeed, as described above,protocol/sequence controller 314 may have similar operation and designas protocol/sequence controller 208. In addition, to the above,protocol/sequence controllers 208 and 314 may incorporate in thedecision process appropriate commands for enabling USB interfaces 222and 316, when the corresponding device may be so connected.

Encryption/decryption component 318 may be further in communication witha secure account number database 320 which stores the security keys fordecrypting the encrypted fob account number. Upon appropriate requestfrom protocol/sequence controller 314, encryption/decryption component(e.g., circuitry 318) may retrieve the appropriate security key, decryptthe fob account number and forward the decrypted account number toprotocol sequence controller 314 in any format readable by any laterconnected POS device 110. In one exemplary embodiment, the accountnumber may be forwarded in a conventional magnetic stripe formatcompatible with the ISO/IEC 7813 standard. Upon receiving the accountnumber in magnetic stripe format, protocol/sequence controller 314 mayforward the account number to POS device 110 via a communicationsinterface 312 and data link 122, as best shown in FIG. 1. POS device 110may receive the decrypted account number and forward the magnetic stripeformatted account number to a merchant network 112 for processing underthe merchant's business as usual standard. In this way, the presentinvention eliminates the need of a third-party server. Further, wherePOS device 110 may receive a response from network 112 (e.g.,transaction authorized or denied), protocol/sequence controller 314 mayprovide the network response to the RF module 302 for optically and/oraudibly communicating the response to fob 102 user.

RFID reader 104 may additionally include a USB interface 316, incommunication with the protocol/sequence controller 314. In oneembodiment, the USB interface may be a RS22 serial data interface.Alternatively, RFID reader 104 may include a serial interface such as,for example, a RS232 interface in communication with theprotocol/sequence controller 314. The USB connector 316 may be incommunication with a personalization system 116 (shown in FIG. 18) forinitializing RFID reader 104 to system 100 application parameters. Priorto operation of system 100, RFID reader 104 may be in communication withpersonalization system 116 for populating database 310 with a listing ofsecurity keys belonging to authorized fobs 102, and for populatingdatabase 320 with the security keys to decrypt fob 102 account numbersplacing the account numbers in ISO/IEC 7813 format. In this way, RFIDreader 104 may be populated with a unique identifier (e.g., serialnumber) which may be used by fob authentication circuitry 210 todetermine if RFID reader 104 may be authorized to receive fob 102encrypted account number.

FIG. 8 illustrates an exemplary flow diagram for the operation of system100. The operation may be understood with reference to FIG. 1, whichdepicts the elements of system 100 which may be used in an exemplarytransaction. The process may be initiated when a customer desires topresent fob 102 for payment (step 802). Upon presentation of fob 102,the merchant initiates the RF payment procedure via an RFID reader 104(step 804). In particular, the RFID reader sends out an interrogationsignal to scan for the presence of fob 102 (step 806). The RF signal maybe provided via the RFID reader antenna 106 or optionally via anexternal antenna 108. The customer may then present fob 102 for payment(step 808) and fob 102 may be activated by the RF interrogation signalprovided.

Fob 102 and RFID reader 104 may then engage in mutual authentication(step 810). Where the mutual authentication may be unsuccessful, anerror message may be provided to the customer via the RFID opticaland/or audible indicator (step 814) and the transaction may be aborted(step 816). Where the mutual authentication may be successful (step814), RFID reader 104 may provide the customer with an appropriateoptical and/or audible message (e.g., “transaction processing” or“wait”) (step 818). The fob protocol/sequence controller 208 may thenretrieve from database 214 an encrypted fob account number and providethe encrypted account number to RFID reader 104 (step 820).

RFID reader 104 may then decrypt the account number and convert theaccount number into magnetic stripe (ISO/IEC 7813) format (step 822) andprovide the unencrypted account number to the merchant system 130 (step828). In particular, the account number may be provided to POS device110 for transmission to the merchant network 112 for processing underknown business transaction standards. POS device 110 may then send anoptical and/or audible transaction status message to RFID reader 104(step 830) for communication to the customer (step 832) and thetransaction is completed (step 834).

It should be noted that the transaction account associated with fob 102may include a restriction, such as, for example, a per purchase spendinglimit, a time of day use, a day of week use, certain merchant use and/orthe like, wherein an additional verification may be required when usingthe fob outside of the restriction. The restrictions may be personallyassigned by fob 102 user, or the account provider. For example, in oneexemplary embodiment, the account may be established such that purchasesabove $X (i.e., the spending limit) must be verified by the customer.Such verification may be provided using a suitable PIN which may berecognized by RFID reader 104 or a payment authorization center (notshown) as being unique to fob 102 holder (e.g., customer) and thecorrelative fob 102 transaction account number. Where the requestedpurchase may be above the established per purchase spending limit, thecustomer may be required to provide, for example, a PIN, biometricsample and/or similar secondary verification to complete thetransaction.

Where a verification PIN may be used as secondary verification theverification PIN may be checked for accuracy against a corroborating PINwhich correlates to fob 102 transaction account number and/or the fobuser's travel-related information. The corroborating PIN may be storedlocally (e.g., on fob 102, or on RFID reader 104) or may be stored on adatabase (not shown) at the payment authorization center. The paymentauthorization center database may be any database maintained andoperated by fob 102 transaction account provider.

The verification PIN may be provided to POS device 110 using aconventional merchant (e.g., POS) PIN key pad 118 in communication withPOS device 110 as shown in FIG. 1, or a RFID keypad in communicationwith RFID reader 104. PIN keypad may be in communication with POS device110 (or alternatively, RFID reader 104) using any conventional data linkdescribed above. Upon receiving the verification PIN, RFID reader 104may seek to match the PIN to the corroborating PIN stored on RFID reader104 at database 310 or 320. Alternatively, the verification PIN may beprovided to a payment authorization center to determine whether the PINmatches the PIN stored on the payment authorization center databasewhich correlates to fob 102 account. If a match may be made, thepurchase may no longer be restricted, and the transaction may be allowedto be completed.

In another exemplary embodiment of the present invention, system 100 maybe configured with one or more biometric scanners, processors and/orsystems. A biometric system may include one or more technologies, or anyportion thereof, such as, for example, recognition of a biometric. Asused herein, a biometric may include a user's voice, fingerprint,facial, ear, signature, vascular patterns, DNA sampling, hand geometry,sound, olfactory, keystroke/typing, iris, retinal or any other biometricrelating to recognition based upon any body part, function, system,attribute and/or other characteristic, or any portion thereof. While theexample discussed herein may include a particular biometric system orsample, the invention contemplates any of the biometrics discussedherein in any of the embodiments.

The biometric system may be configured as a security system and mayinclude a registration procedure in which a user of transactioninstrument (e.g., fob 102) proffers a sample of his fingerprints, DNA,retinal scan, voice, and/or other biometric sample to an authorizedsample receiver (ASR). An ASR may include a local database, a remotedatabase, a portable storage device, a host system, an issuer system, amerchant system, a fob issuer system, an employer, a financialinstitution, a non-financial institution, a loyalty point provider, acompany, the military, the government, a school, a travel entity, atransportation authority, a security company, and/or any other system orentity that is authorized to receive and store biometric samples andassociate the samples with specific biometric databases and/ortransaction instruments (e.g., fobs 102). As used herein, a user of afob, fob user, or any similar phrase may include the person or deviceholding or in possession of the fob, or it may include any person ordevice that accompanies or authorizes the fob owner to use the fob. Byproffering one or more biometric samples, a biometric may be scanned byat least one of a retinal scan, iris scan, fingerprint scan, hand printscan, hand geometry scan, voice print scan, vascular scan, facial and/orear scan, signature scan, keystroke scan, olfactory scan, auditoryemissions scan, DNA scan, and/or any other type of scan to obtain abiometric sample.

Upon scanning the sample, the system may submit the scanned sample tothe ASR in portions during the scan, upon completing the scan or inbatch mode after a certain time period. The scanned sample may include ahardcopy (e.g., photograph), digital representation, an analog versionor any other configuration for transmitting the sample. The ASR mayreceive the sample and the ASR may also receive copies of a fob user'sbiometric data along with the sample or at a different time (or within adifferent data packet) from receiving the sample.

The ASR and/or fob user 102 may store the sample in digital and/or anystorage medium known in the art and correlate and/or register the samplewith fob user information. By storing the sample in digital format, theASR may digitize any information contained in one of the biometric scansdescribed herein. By storing the sample in any storage medium, the ASRmay print and/or store any biometric sample. Hardcopy storage may bedesirable for back-up and archival purposes. As used herein, registeredsamples may include samples that have been proffered, stored andassociated with user information.

The biometric sample may also be associated with user information. Thesample may be associated with user information at any step in theprocess such as, for example, prior to submission, during submissionand/or after submission. In one embodiment, the user may input a PINnumber or zip code into the POS terminal, then scan the biometric tocreate the biometric sample. The local POS system may associate thebiometric sample data with the PIN and zip code, then transmit theentire packet of information to the ASR. In another embodiment, the POSmay facilitate transmitting the sample to an ASR, and during thetransmission, the sample may be transmitted through a third system whichadds personal information to the sample.

The information associated with the biometric sample may include anyinformation such as, for example, fob user information, fob 102information, fob 102 identifier information, fob 102 vender information,fob 102 operability information, and/or fob 102 manufacturinginformation. Fob 102 information is not limited to transponderinformation and may include information related to any transactioninstrument such as smart fobs, credit fobs, debit fobs,merchant-specific fobs, loyalty point fobs, cash accounts and any othertransaction instruments and/or accounts. The fob user information mayalso contain information about the user including personalinformation—such as name, address, and contact details; financialinformation—such as one or more financial accounts associated with thefob user; loyalty point information—such as one or more loyalty pointaccounts (e.g., airline miles, charge fob loyalty points, frequent dinerpoints) associated with the fob user; and/or non-financialinformation—such as employee information, employer information, medicalinformation, family information, and/or other information that may beused in accordance with a fob user.

For example, fob user may have previously associated a credit cardaccount, a debit card account, and a frequent flier account with hisbiometric sample which is stored at an ASR. Later, when fob user desiresto purchase groceries, fob user may submit his biometric sample whileusing fob 102 for the purchase at a POS. The POS may facilitate sendingthe biometric sample to the ASR such that the ASR authorizes thebiometric sample and checks a look-up table in the ASR database todetermine if any information is associated with the sample. Ifinformation (e.g., financial accounts) is associated with the sample,the ASR may transmit the information to the POS terminal. The POSterminal may then present fob user with a list of the three accountsassociated with the biometric sample. Fob user and/or a merchant maythen choose one of the accounts in order to continue and finalize thetransaction.

The ASR and/or fob user may associate a specific fob 102 identifier withthe biometric sample by any method known in the art for associating anidentifier (e.g., through the use of software, hardware and/or manualentry). The ASR may additionally verify the fob user and/or fob 102 byusing one or more forms of the user's secondary identification. Forexample, the ASR may verify the fob user by matching the fob informationto information retrieved from scanning information from a fob user'sdriver's license. The ASR may verify fob 102 by contacting the vendor offob 102 to confirm that fob 102 was issued to a specific fob user. Inanother embodiment, the ASR may activate fob 102 during the registrationprocedure to confirm that fob 102 transponder identifier and otherinformation is properly associated with the fob user and the fob user'sspecific biometric samples. The ASR may additionally employ one or moreverification methods to confirm that the biometric sample belongs to theuser, such as, for example, the ASR may request from the userdemographic information, further biometric samples and/or any otherinformation. As used herein, “confirm,” “confirmation” or any similarterm includes verifying or substantially verifying the accuracy,existence, non-existence, corroboration, and/or the like of theinformation, component, or any portion thereof. The ASR may additionallyemploy one or more additional processing methods in order to facilitateassociation of a biometric sample. As used herein, the term processingmay include scanning, detecting, associating, digitizing, printing,comparing, storing, encrypting, decrypting, and/or verifying a biometricand/or a biometric sample, or any portion thereof.

Upon association, authentication and/or verification of the biometricsample and fob 102, the system may store the sample and fob 102identifier in one or more databases on and/or in communication withsystem 100 via a network, server, computer, or any other means ofcommunicating as described herein. The database(s) may be any type ofdatabase described herein. For example, a biometric sample stored on fob102 may be stored in database 212. The database(s) may be located at oroperated by any of the entities discussed herein such as, for example,the ASR and/or by a third-party biometric database operator.

The system may further protect the samples by providing additionalsecurity with the sample. The security may include, for example,encryption, decryption, security keys, digital certificates, firewallsand/or any other security methods known in the art and discussed herein.One or more security vendors may utilize the security methods to storeand/or access the biometric samples. The present invention anticipatesthat storage of the biometric samples may be such that a sample is firstencrypted and/or stored under a security procedure, such that the samplemay only be accessed by a vendor with the proper level of access orsecurity which corresponds to or provides access to the stored sample.The samples may be accessible by certain vendors such as, for example,fob 102 transaction account provider system, an issuer system, amerchant system, a fob issuer system, an employer, a financialinstitution, a non-financial institution, a loyalty-point provider, acompany, the military, the government, a school, a travel entity, atransportation authority, and/or a security company.

The fob of the invention may include a particular security systemwherein the security system incorporates a particular biometric system.As shown in FIG. 9, fob 102 may include a biometric security system 902configured for facilitating biometric security using, for example,fingerprint samples. As used herein, fingerprint samples may includesamples of one or more fingerprints, thumbprints, palmprints,footprints, and/or any portion thereof. Biometric security system 902may include a biometric sensor 904 which may be configured with a sensorand/or other hardware and/or software for acquiring and/or processingthe biometric data from the person such as, for example, opticalscanning, capacitance scanning, or otherwise sensing the portion of fobuser. In one embodiment, biometric sensor 904 of the security system 902may scan a finger of a fob user in order to acquire his fingerprintcharacteristics into fob 102. Biometric sensor 904 may be incommunication with a sensor interface/driver 906 such that sensorinterface 906 may receive the fingerprint information and transmits asignal to controller 208 to facilitate activating the operation of fob102. A power source (e.g., battery 903) may be in communication withbiometric sensor 904 and sensor interface 906 to provide the desiredpower for operation of the biometric security system components.

In one exemplary application of fob 102 incorporating biometric securitysystem 902, the user may place his finger on the biometric sensor toinitiate the mutual authentication process between fob 102 and RFIDreader 104, and/or to provide verification of the user's identity. Fob102 may digitize the fingerprint and compare it against a digitizedfingerprint stored in a database (e.g., security database 212) includedon fob 102. The fingerprint information may additionally be comparedwith information from one or more third-party databases communicatingwith fob 102 through any communication software and/or hardware,including for example, RFID reader 104, a USB connection, a wirelessconnection, a computer, a network and/or any other means forcommunicating. This transfer of information may include use ofencryption, decryption, security keys, digital certificates and/or othersecurity devices to confirm the security of the sample. Fob 102 mayadditionally communicate with third-party databases to facilitate acomparison between fob 102 identifier and other fob identifiers storedwith the biometric samples. As used herein, compare, comparison andsimilar terms may include determining similarities, differences,existence of elements, non-existence of elements and/or the like.

Protocol/sequence controller 208 may facilitate the local comparison toauthenticate the biometric and authentication circuit 210 may validatethe information. Any of the embodiments may alternatively oradditionally include remote comparisons performed or controlled by oneor more third-party security vendors. One or more comparison techniquesand/or technologies may be used for comparisons. For example, forfingerprint comparisons, protocol/sequence controller 208 may utilize anexisting database to compare fingerprint minutia such as, for example,ridge endings, bifurcation, lakes or enclosures, short ridges, dots,spurs and crossovers, pore size and location, Henry System categoriessuch as loops, whorls, and arches, and/or any other method known in theart for fingerprint comparisons.

Fob 102 may additionally be configured with secondary securityprocedures to confirm that fake biometric samples are not being used.For example, to detect the use of fake fingers, fob 102 may be furtherconfigured to measure blood flow, to check for correctly aligned ridgesat the edges of the fingers, and/or any other secondary procedure toreduce biometric security fraud. Other security procedures for ensuringthe authenticity of biometric samples may include monitoring pupildilation for retinal and/or iris scans, pressure sensors, blinkingsensors, human motion sensors, body heat sensors and/or any otherprocedures known in the art for authenticating the authenticity ofbiometric samples.

After verifying the biometric information, fob 102 and RFID reader 104may begin mutual authentication, and the transaction may proceedaccordingly. However, the invention contemplates that the verificationof biometric information may occur at any point in the transaction suchas, for example, after the mutual authentication. At any point in thetransaction, the system may additionally request fob user to enter a PINand/or other identifier associated with the transaction account and/orbiometric sample to provide further verification of fob user'sidentification. As part of the transaction, fob user payer may berequested to select from one of the financial accounts, loyaltyaccounts, credit accounts, debit account, and/or other accountsassociated with the biometric sample. The user may be presented with alist of account options on a display associated with RFID reader 104,fob 102, a third-party security device and/or any other financial ortransaction device association with a transaction. In anotherembodiment, a payee may select one of the accounts. For example, adepartment store payee may manually and/or automatically select adepartment store issued account, if available, for a transaction.

The present invention includes systems and methods for facilitatingpersonalizing and dynamically synchronizing fobs and associateddatabases in the context of a distributed transaction system. Moreparticularly, referring now to FIG. 10, an exemplary dynamicsynchronization system (DSS) may comprise a support client server 1004(e.g., a secure server), a fob object database update system 1006(FODUS), one or more enterprise data synchronization interfaces 1008(EDSI), an update logic system 1010, one or more enterprise datacollection units 1012 (EDCUs), and one or more POS devices 110configured with RFID reader 104 to interoperably accept information fromand interface with fobs 102. In an exemplary embodiment, DSS may alsosuitably comprise a personalization system 116 and an accountmaintenance system 142 configured to communicate with FODUS 1006.

More particularly, in an exemplary embodiment, secure support clientserver 1004 may communicate over a suitable network to EDSIs 1008through enterprise networks 1014. EDSIs 1008 communicate with updatelogic system 1010, which itself communicates with enterprise datacollection units 1012. Enterprise data collection units 1012 communicatewith FODUS 1006 and secure support client server 1004. In general, asdescribed in further detail below, each enterprise (e.g., airlinepartner, hotel partner, travel agency, etc.) may be associated with acorresponding EDSI 1008, network 11014, and EDCU 1012. That is, EDCU1012(a) corresponds to EDSI 1008(a) and network 1014(a), EDCU 1012(b)corresponds to EDSI 1008(b) and network 1014(b), and so on. The DSS mayinclude an arbitrary number of such functional blocks in accordance withthe number of enterprises represented.

Personalization system 116 may suitably function as the issuing sourceof fobs 102. That is, personalization system 116 facilitates creatingand issuing fobs for use by the consumer by providing a predeterminedfile structure populated with initialization data (e.g., accountnumbers, serial numbers, default preferences, and the like). In thisregard, FODUS 1006 interfaces with personalization system 116 in orderto facilitate re-issuance of the fob by providing updated data in theevent a fob is destroyed, lost, or stolen. Personalization system 116 isdescribed in detail below in conjunction with FIG. 18.

Account maintenance system 142 may be provided for customer servicepurposes and, in this capacity, may act as the point of entry for fobuser complaints, questions, and other customer input. FODUS 1006 maysuitably communicate with account maintenance system 142 in order toassist customer service representatives and/or automated systems inaddressing fob user issues.

Fob POS Devices

POS devices 110 may allow the fob user to gain access to the distributedtransactions system through a variety of means. Such POS devices mayinclude, for example, standard home telephones, various PCS wirelesssystems, pay phones, palmtops computers, notebook computers, Internetworkstations, automated teller machines (ATMs), point-of-sale terminals(POS) stand-alone kiosks, network computers (NCs), personal dataassistants (PDAs), or any other suitably configured communicationapparatus. POS device 110 may be portable (as in the case of PDAs andcellular phones) or centrally located, for example, in airline ticketingand gate areas, rental car facilities, hotel lobbies, travel agencies,and malls. In addition, businesses may host POS device 110 to streamlinetheir employees' business travel. In an exemplary embodiment, variousPOS devices 110 may be configured to interface with (or incorporate)contactless fobs 102 or fob receivers in accordance with the relevantportions of the ISO-14443 standard.

Secure Support Client Server

Secure support client server 1004 may provide, where appropriate, anyfunctionality missing from the individual POS devices 110 used during atransaction. Server 1004 also suitably handles routing of messages fromPOS device 110 to the appropriate EDSI 1008 and/or EDCU 1012.

Referring now to FIGS. 10 and 11, an exemplary secure support clientserver 1004 may comprise a security engine 1102, a supplementalapplication support 1104, and a router 1106. Security engine 1102 maycomprise suitable hardware and/or software configured to providemessaging (e.g., secure messaging) between server 1004, EDSUs 1012, andnetworks 1014. More specifically, security engine 1102 utilizesauthentication, data encryption, and digital signature techniques inconnection with incoming and outgoing message packets. A variety ofconventional security algorithms are suitable in the context of thepresent invention, including, for example, DES encryption, RSAauthentication, and a variety of other symmetrical and non-symmetricalcryptographic techniques.

Supplemental application support 1104 may comprise suitable hardwareand/or software components related to specific POS device 110functionality. More particularly, server 1004 may suitably determine thenature of POS device 110 utilized during a transaction. If POS device110 does not include the appropriate software for effecting therequested transaction, then server 1004 supplies the functionality(i.e., software modules) which completes the transaction with respectiveEDSIs 1008 and/or EDCUs 1012. The supplemental functionality mayinclude, inter alia, software modules for properly formatting messagepackets (described in further detail below) sent out over the variousnetworks comprising the DSS. For example, where a transaction takesplace via POS device 110 which may consist entirely of a stand-aloneRFID reader 104, then nearly all functionality may be supplied by server1004 because RFID reader 104, by itself, may only be capable oftransferring messages to and from fob 102 in a “dumb” manner. However,when a suitably configured PC and/or RFID reader 104 is configured withPOS device 110, most functionality may be supplied by various softwaremodules residing in the PC and/or RFID reader 104. In such a case,server 1004 may only transfer the various message packets to and fromPOS device 110 without supplying additional software. Addedfunctionality may be supplied through any suitable method, for example,through the use of portable software code (e.g., Java, ActiveX, and thelike), or distributed software residing within POS device 110, fobs 102,RFID reader 104 and/or server 1004.

Router 1106 suitably handles routing of messages to the appropriateEDCUs 1012, networks 1014, and POS device 110. That is, router 1106 maybe configured to identify the appropriate functional blocks within theDSS to which a given message packet should be sent. The identificationof the appropriate functional blocks may take place in a number of ways.In an exemplary embodiment, the identification may be accomplishedthrough the use of a look-up table comprising a list of appropriatedestinations keyed to information extracted from requests received fromPOS device 110.

In an alternate embodiment, a secure support client server 1004 may notbe used, and the functionality of POS devices 110 may be suitablyspecified in order to obviate the need for server 1004. Alternatively,the functions of server 1004 may be allocated and distributed throughoutthe DSS components in any advantageous manner.

It will be appreciated by those skilled in the art that the term“transaction” refers, generally, to any message communicated over thesystem for effecting a particular goal, for example, travel transaction,financial transaction, debit/charge authorization, preference changes,reservation requests, ticket requests, and the like. FIG. 7, forexample, shows an exemplary transaction data structure useful in thecontext of performing an on-line transaction with a travel partner,wherein the field name 702, data type 704 ('C′ for character), maximumbyte-length 706, and description 708 are listed in tabular form. In thisexample, the transaction messages suitably may comprise comma delimiteddata packets, although other data structures may be employed.

Fob Object Database Update System (FODUS)

FODUS 1006 suitably stores information (e.g., securely stores) relatedto the state of the various issued fobs 102. Referring now to FIGS. 10and 15, in an exemplary embodiment, FODUS 1006 may comprise a securityengine 1502, a data management module 1504, a fob object database 212, afob object administration module 1506, and an audit file 1508.

Security engine 1502 may provide suitable security for, inter alia, theinformation stored within fob object database 212. In this regard,security engine 1502 may utilize various authentication, dataencryption, and digital signature techniques in connection with incomingand outgoing message packets. Suitable algorithms in the context of thepresent invention, include, for example, DES encryption, RSAauthentication, and a variety of other symmetrical and non-symmetricalcryptographic techniques.

Data management module 1504 may suitably act as a data interface betweenFODUS 1006 and account maintenance 142 as well as between FODUS 1006 andthe various EDCUs 1012. More specifically, module 604 facilitatesconverting and translating between the data format used in thesesystems. For example, data stored within object database 106 may not bestored in a format which may be easily used by EDCUs 1012 or accountmaintenance 142. Accordingly, data management module 1504 may comprisesuitable routines for effecting conversion and formatting of bothincoming and outgoing data.

Fob object administration module 1506 may provide suitable databasesoftware to edit, update, delete, synchronize, and ensure substantialnon-corruption of data stored within object database 212. A variety ofdatabase packages are suitable for this task, including, for example,various conventional fourth-generation relational database managementsystems (4GL RDBMS).

Audit file 1508 may suitably track changes to object database 116,thereby helping to ensure the integrity of fob data stored within FODUS1006. More particularly, when changes to object database 116 take placeas a result of preference updates, transactions, application structurechanges, and the like, audit file 1508 may track suitable informationrelated to these changes (e.g., time, date, and nature and content ofthe change).

Fob object database 212, which may comprise a single database or a setof distributed databases, may be used to store the known state of thevarious fobs 102. In general, the state of a fob may be characterized bya suitable set of fob indicia. In an exemplary embodiment, wherein adata structure in accordance with ISO-7816 is employed, fob objectdatabase 212 stores information related to the individual applicationspresent on the various fobs 102 (i.e., the overall file structure) aswell as the individual fields, directories, and data that may comprisethose applications. A file structure for fob object database 212 may bechosen such that it includes a suitable set of data fields for a givenfob 102.

Enterprise Data Synchronization Interface

In an exemplary embodiment, the various EDSIs 1008 may track changes tofob data and/or applications corresponding to individual enterprises.With reference to FIGS. 10 and 12, in an exemplary embodiment, EDSI 1008may comprise a communication server 1202, a security engine 1204, and acustomer database 1206.

Communication server 1202 may suitably facilitate communication withnetworks 112 and update logic system 1010. In this regard, server 302may be configured to translate between various formats, media, andcommunication protocols as may be necessary or desired given theparticular choice of components employed.

Security engine 1204 may provide suitable security measures with respectto the access and storage of information with customer database 1206.Security engine 1204 may utilize various authentication, dataencryption, and digital signature techniques in connection with incomingand outgoing message packets. Suitable algorithms in the context of thepresent invention, may include, for example, DES encryption, RSAauthentication, and a variety of other symmetrical and non-symmetricalcryptographic techniques.

Customer database 1206 may suitably provide a means for storing fobinformation related to individual partners or enterprises. That is, aparticular enterprise (hosting, for example, network 112(a)) maycompile, or employ others to compile, fob information related only tothat enterprise. For example, a hotel chain may store loyalty,preference, and other data that relates specifically to that hotelchain. During synchronization (as described in further detail below) anychanges to database 306 may be propagated through the system and,visa-versa, changes elsewhere in the system may be communicated todatabase 306. This communication may be done securely (using securityengine 1204) in conjunction with communication server 1202.

In an alternate embodiment, the functionality provided by the EDSIs 1008may be folded into the corresponding EDCU 1012. That is, while anillustrated embodiment may employ one or more physically separate EDSIs1008, it may be advantageous to further streamline the DSS byincorporating this functionality into the corresponding EDCU 1012functional block.

Update Logic System

In an exemplary embodiment, update logic system 1010 may format andsecurely routes fob data received from and transmitted to EDCUs 1012 andEDSIs 1008. Referring now to FIG. 13, in an exemplary embodiment, updatelogic system 1010 may include a logic engine 1302, a data managementmodule 1304, a security engine 1306, an enterprise update administrator1308, and an enterprise update audit module 1310.

Logic engine 1302 may suitably function to direct and distributeinformation changes across the system. Thus, logic engine 1302 may beable to determine which modules (i.e., which EDCUs 1012 and EDSIs 1008)need to reflect the change.

Data management module 1304 may suitably act as a data interface betweenEDSIs 1008 and EDCUs 1012. More specifically, module 1304 may be able toconvert and translate between data format used in these systems.Accordingly, data management module 1304 may comprise suitable routinesfor effecting conversion and formatting of both incoming and outgoingdata.

Security engine 1306 may be used to provide suitable security measureswith respect to data flowing through update logic system 1010. Securityengine 1306 may utilize various authentication, data encryption, anddigital signature techniques in connection with incoming and outgoingmessage packets. Suitable algorithms in the context of the presentinvention, may include, for example, DES encryption, RSA authentication,and a variety of other symmetrical and non-symmetrical cryptographictechniques.

Enterprise update administrator 1308 may suitably comprise overheadsoftware used to maintain data transfer between EDSIs 1008 and EDCUs1012.

Enterprise update audit module 1310 may suitably track updatedinformation flowing through update logic system 1010. More particularly,when information is communicated across update logic system 1010 (as aresult of preference updates, transactions, application structurechanges, and the like), audit module 1310 may track suitable indicia ofthis information (e.g., time, date, and nature and content of thecommunication).

Enterprise Data Collection Unit

EDCUs 1012 may facilitate storing and coordinating the transfer ofsynchronization data corresponding to a particular enterprise. Withreference to FIG. 14, in an exemplary embodiment, enterprise datacollection unit 1012 may include a security engine 1408, a customerupdate transaction database 1404, a customer loyalty transactiondatabase 1410, a customer pending transaction database 1414, an updatedatabase 1402, an EDCU audit file 1406, an EDCU administrative file1412, and an EDCU data management module 1416.

Security engine 1408 may be used to provide suitable security measureswith respect to data flowing through EDCU 1012. Toward this end,security engine 1408 may utilize various authentication, dataencryption, and digital signature techniques in connection with incomingand outgoing message packets. Suitable algorithms in the context of thepresent invention, may include, for example, DES encryption, RSAauthentication, and a variety of other symmetrical and non-symmetricalconventional cryptographic techniques.

Customer update transaction database 1404 may be used to storeinformation which has been updated on a fob 102, but which has not yetpropagated to the various databases and networks that require updating.For example, a fob 102 may be used to change fob user preferences in thecourse of a transaction with a particular enterprise. This informationmay, in the short term, be stored in database 1404 (for the particularenterprise) until it could be fanned-out to FODUS 1006 and theappropriate EDCUs 1012 and EDSIs 1008. This type of transaction isdescribed in further detail below.

Customer loyalty transaction database 1410 may be suitably used to storeloyalty information (e.g., frequent flier, frequent stayer, etc.)associated with a particular enterprise or partner. In an alternateembodiment, a loyalty transaction database 1410 may not beemployed—rather, the functionality of database 1410 may be incorporatedinto databases 1402, 1410, and 1414 such that a loyalty transactionbecomes just another transaction modality to be tracked by EDCU 1012.

Customer pending transaction database 1414 may be suitably used to storeinformation related to transactions which have taken place withoutdirect use of the fob 102. More particularly, some transactions, such aspreference changes and the like, may be initiated by a fob user througha channel which does not involve use of the fob, for example, through averbal request over a standard telephone. In such a case, and asdetailed further below, this data may be suitably stored in pendingtransaction database 1414. The transaction data remains in database 1414until the corresponding fob 102 may be used in conjunction with POSdevice 110, whereupon fob 102 itself (as well as FODUS 1006) may beupdated with this new information.

Update database 1402 may be suitably used to store other types oftransactions (i.e., transactions which may not be classifiable asupdate, loyalty or pending). For example, update database 1402 may beemployed to store file structure updates as detailed below.

Audit file 1406 may be used to track changes to update database 1404,pending database 1414, database 1402, and, in an illustrated embodiment,loyalty database 1410. In an alternate embodiment, wherein no separateloyalty database 1410 is used, audit file 1406 may track changes todatabases 1404, 1414, and 1402. Audit file 1406 therefore may help toensure the integrity of data in the respective files.

Administrative file 1412 may provide suitable database softwareconfigured to edit, update, delete, synchronize, and ensurenon-corruption of data stored within the various databases that maycomprise EDCU 1012 (i.e., databases 1402, 1404, 1410, and 1414).

Data management module 1416 may provide data management capabilities tofacilitate data transfer between fobs 102 and databases 1404, 1414,1402, and 1410 as well as between these databases and the other systems(i.e., update logic system 1010 and FODUS 1006). Thus, data managementmodule 1416 may act as interface to ensure seamless transfer of databetween the various systems.

Network

The various components, databases, modules, and apparatus describedabove in connection with the invention are connected via a suitable datacommunication network. Such a network may consist of various physicalconnections using a variety of conventional data protocols, for example,the TCP/IP protocol. It will be appreciated that the individualconnections between components of the present system may differ. Forexample, a wireless PCS network may be employed from POS device 110 tosecure support client server 1004, while an Internet TCP/IP connectionmay be employed from FODUS 1006 to the various EDCUs 1012.

Those skilled in the art will appreciate that a variety of hardwaresystems are suitable for implementing the present invention. Variousmodems, routers, CPU's, monitors, back-up systems, power-supplies, andperipherals may be employed to realize the benefits of the presentsystem. In one embodiment, for example, a Compaq Prolinea computeroperating in an OS/2 environment using IBM MQ Server software may beused to implement secure support client server 1004, wherein the variousPOS devices may comprise stand-alone fob kiosks, an EDCU 1012 and FODUS116 may then be implemented on a Compaq Prolinea computer operating in aWindows/NT environment running a suitable database software package.

Personalization System

Referring now to FIG. 18, in an exemplary embodiment, personalizationsystem 116 may suitably comprise a fob management system 1802, a legacymanagement system 1804, a gather application module 1806, one or moredatabases 1810, an activation block 1808, a common fob personalizationutility 1812 (CCP), a service bureau 1814, a common fob security server1816, a key management system 1818, and one or more key systems 1820.Personalization system 116 may be in communication with fob 102 via RFISO 14443 interface 114 for populating fob database 212 with thesecurity keys for facilitating authentication of the unique RFID reader104 identifier. In addition, personalization system 116 may populate ondatabase 212 a unique fob 102 identifier for use by RFID reader 104 indetermining whether fob 102 may be authorized to access system 100.Personalization system 116 may populate (e.g., inject) the encrypted fob102 account number into fob database 214 for later providing toauthenticated RFID reader 104. Personalization system 116 mayadditionally populate travel-related information into fob database 212for later providing to RFID reader 104, third-party travel partners,and/or issuer systems.

In one exemplary embodiment, personalization system 116 may include anystandard computing system as described above. For example,personalization system 116 may include a standard personal computercontaining a hardware security module operable using any conventionalgraphic user interface. Prior to populating the security key informationaccount number, unique identifying information, and travel-relatedinformation into fob 102 or RFID reader 104, the hardware securitymodule may authenticate fob 102 and RFID reader 104 to verify that thecomponents are authorized to receive the secure information.

Key management system 1818 may suitably comprise a database module, CIDreplace module, key system, and key system. CCP 1812 may suitablycommunicate with FODUS 1006 (shown in FIG. 10), and legacy managementsystem 1804 may suitably communicate with account maintenance 142 whichmay also be configured to communicate with FODUS 1006.

Fob management system 1802 may suitably receive the fob request 1801 andinitiate the gathering of information from various sources. Generally,fob request 1801 may consist of various request information intended tospecify a desired group of fob characteristics. Such characteristics mayinclude, for example: a list of desired applications (airline, hotel,rental car, etc.); a designation of whether the fob is new, a renewal,or a replacement; a list of default fob user preferences correspondingto the desired applications; personal information related to the fobuser (name, address, etc.); and required security levels.

Fob management system 1802 may suitably parse the fob request and, forinformation already stored by the issuer, sends a request to legacy fobmanagement system 1804. For information not available as legacy data,fob management system 1802 may forward the relevant components of fobrequest 1801 to gather application module 1806. In an exemplaryembodiment, fob management system 1802 may choose the optimum fobphysical characteristics for a particular fob request 1801. That is, fobmanagement system 1802 may suitably determine the appropriate type offob chip to be used based on a number of factors, for example, memoryrequirements and computational complexity of the desired securityfunctions. Similarly, the optimum protocol/sequence controller may bechosen. In an alternate embodiment, the fob transponder,protocol/sequence controller, and the like, may be specified in fobrequest 1801.

Legacy management system 1804 may act as a suitable repository ofinformation related to the fob user's past relationship, if any, withthe fob issuing organization. For example, a fob user may have along-standing credit or debit account with issuing organization (basedon a standard embossed mag-stripe fob) and this information may beadvantageously incorporated into the issued fob.

Gather application module 1806 may be suitably configured to receiveinformation from fob management system 1802 and legacy management system1804 and then interface with the various databases 1810 to gather allremaining application information specified in fob request 1801. In anexemplary embodiment, databases 1810 may correspond to and be associatedwith the individual partnering enterprises which offer fob applicationsfor use in fob 102 (e.g., networks 112 in FIG. 10). Thus, for example, afob request 1801 which included a request for a hotel application maytrigger gather application 1806 to initiate data communication with theappropriate hotel database 1810. Hotel database 1810 may then returninformation specifying the correct file structure, access conditions(security), default values, and other data to configure fob 102 with therequested application. Communication with the various databases 1810 maytake place through any suitable means, for example, data communicationover the Internet, PSTN, and the like, or through other channels, suchas simple phone requests.

Activation block 1808 may be suitably used to provide a means for thefob user to activate the fob once it has been issued. For example, itmay be common for credit fobs and the like to be sent to the fob userunactivated, requiring that the fob user call (or otherwise contact) anautomated system at the issuer in order to activate the fob. This maytypically be accomplished via entry of the fob number and other suitableID using a touch-tone phone. In this regard, activation block 1808 maybe used to facilitate this function for the requested fob (i.e., tospecify whether such activation is desired or necessary for a particularfob).

CCP 1812 may be used to create a correctly formatted fob “object” (i.e.,the operating system, file structure and all other available fob data tobe downloaded to fob 102) then transfer this information to servicebureau 1814 (for creation of the fob) and FODUS 1006 (for recording thefob's state as issued). CCP 1812 may be configured to tailor the formatof the fob object to the specific fob issuance system to be used(described below). Thus, gather application system 1806 may deliver arelatively high-level functionality request, and CCP 1812 can create thespecific “object” to be used in the implementation.

Personalization Service Bureau 1814 may comprise suitable hardwareand/or software components to complete production of the fobs forissuance to the respective fob users. In this regard, service bureau1814 may include a suitable fob “printer” to handle the transfer ofinformation to the fob chip as well as any conventional embossing ormag-stripe writing that may take place.

Common fob security server 1816 (CCSS) may suitably comprise softwareand/or hardware components to retrieve cryptographic key informationfrom various enterprise key systems 1820. In an exemplary embodiment,this information may be accessed by service bureau 1814 in order tocomplete the personalization process. More particularly, it maytypically be the case that a fob 102 contains a number of differentapplications associated with a wide range of enterprise organizations.One skilled in the art will appreciate that the writing, updating, andreading of these files may be advantageously restricted to particularparties in accordance with a set of access condition rules. These accessconditions may be suitably implemented using cryptographic keys whichare known by the appropriate parties. Thus, service bureau 1814, whosetask it is to create and populate the fob file structure, may not, abinitio, have access to the keys to perform this function. As mentionedbriefly above, known systems have attempted to solve this problem byaccumulating key data in a central repository used in the issuanceprocess, thereby creating an unacceptable security risk. Methods inaccordance with the present invention, however, may allow forcommunication between the fob and the individual key systems 1820 as thefob is being issued, thus allowing key information to be securelydownloaded to the fob without the intervention of a third party. CCSS1816 may be suitably used to facilitate this process by receivinginformation from CCP 1812 regarding the identity of the variousapplications to be created in the various fobs, then, when prompted byservice bureau 1814 (or, alternatively, prior to issuance by servicebureau 1814), contacting the appropriate key system 1820 to request akey to be transmitted to service bureau 1814 during personalization.

Key systems 1820 may comprise suitable database systems capable ofstoring, generating, and securely transmitting cryptographic keysassociated with a particular enterprise. Key management system 1818 maybe, in this context, a system comparable to key systems 1820, but whichis “owned” by the party implementing the personalization system. Thekey-generating function may be distributed between CCSS 1816 and keysystems 1820. That is, the keys may be generated in real time at CCSS1816 (in accordance with algorithms and key information received fromthe particular enterprises), rather than being generated at key systems1820.

It will be appreciated to one skilled in the art that the functionalblocks illustrated in FIG. 18 may be implemented using a variety ofhardware and/or software components, both off-the-shelf and/orcustom-developed. Database-intensive functions performed, for example,by fob management system 1802, may be implemented using any suitabledatabase package, (e.g., Codebase, dBase, or the like).

Personalization Process

A personalization system as described above in conjunction with FIG. 18may be suitably used to efficiently issue a large number of fobs with awide range of functionality levels. This task may involve obtaining andcoordinating, in a timely fashion, accurate data for individual fobusers across the various partnering enterprises supported by the system.In this regard, it may be the case that certain partnering enterprisesdesire to limit the dissemination of proprietary data. This data mayinclude, for example, private keys used in connection with fob accessconditions as well as file structure and fob user personal data.

Referring now to FIGS. 18 and 19, an exemplary fob personalizationprocess will now be described. First, the system may receive a fobrequest (step 1902). As mentioned above, fob management system 1802 maybe suitably used to receive the fob request and initiate the gatheringof information from various sources. Fob request 1801 may suitablyconsist of request information intended to specify a desired group offob characteristics. Such characteristics may include, for example: alist of desired applications (airline, hotel, rental car, etc.); adesignation of whether the fob is new, a renewal, or a replacement; alist of default fob user preferences corresponding to the desiredapplications; personal information related to the fob user (name,address, etc.); and required security levels.

Next, in step 1904, the system may select the fob type and configurationappropriate for the given fob request 1801. This step may be suitablyperformed by fob management system 1802. Thus, fob management system1802 may examine a number of factors in light of information received infob request 1801 (e.g., memory requirements, desired security functions,and the like), then may select an appropriate fob chip from a library ofavailable chips. In the same way, the optimum fob operating system (FOS)may also be selected.

In step 1906, fob user information may be obtained. This step may besuitably performed by gather application module 1806 operating inconjunction with databases 1810 and legacy management system 1804. Moreparticularly, fob user-specific information may be classified in twogroups: information known to the personalization system, and informationnot known by the personalization system. Known information generally mayconsist of data acquired through a past relationship with theorganization hosting the personalization system. In such a case, certaindata such as fob user name, preferred billing address, title, company,etc., may most likely already be known, as will certain applicationdata. Such information may be suitably stored in, and may be retrievedfrom, one or more databases comprising legacy management system 1804. Aspart of step 1906, the system (specifically, module 1808) may determinewhether the fob should require activation. That is, as mentioned brieflyabove, it may be common to apply a sticker or the like to a fob thatnotifies the fob user that activation of the fob is required prior touse. Activation typically involves the use of an automated phone systemor interne website). The choice of whether a particular fob requiresactivation may be based on a number of factors, for example,demographics, crime-rate numbers, or mail fraud statistics associatedwith the fob user's zip-code number.

For data not included in legacy management system 1804, gatherapplication module 1806 may suitably communicate with databases 1810 toretrieve the information needed to satisfy fob request 1801. Thisinformation may typically consist of file structure information (e.g.,the DF and EF hierarchy, data types and lengths, and access conditionspecifications for the particular enterprise-sponsored application). Forexample, in the case where fob request 1801 may include a request for anairline application, gather application module 1806 may contact thedatabase corresponding to the enterprise hosting the airlineapplication, then download the relevant file structure information. Thisprocess may continue in turn for each new or modified application to beincorporated into the fob.

In step 1908, a full fob user data set may be created, suitably usingCCP 1812. This data set, or “fob object,” may ultimately be used byservice bureau 1814 to create the physical fob. The form of the fobobject may vary. In one embodiment, the fob object may comprise a BinaryLarge Object (“BLOB”). The fob object may be tailored to the selectedfob configuration (e.g., chip type and operating system as specified instep 1904), the content of fob user information data (gathered in step1906), and the intended fob “printer” (i.e., the apparatus used tocreate the finished fob within service bureau 1814). This allows thesystem, in the preceding steps, to specify file structures, data types,and the like, without concerning itself with how this structure will beencoded onto the fob or how the data will be accessed. Up until step1908, the system need only develop a relatively high-level model of theintended fob data structure; the specifics may be substantiallyinvisible to all but CCP 1812.

In an alternate embodiment, various details of the fob data object maybe determined at a prior point in the system. That is, the functionalityof CCP 1812 may be distributed among various components of the system.

Having created the fob user data set, or fob object, in step 1908, thisdata may then be sent to FODUS 1006 (step 1910). This ensures that theDSS (particularly FODUS 1006) has a record of the fob state at the timeof personalization. This information may then be immediately availableto account maintenance system 142.

The fob object may then be sent to service bureau 1814 and (if required)CCSS 1816 (step 1912). In step 1914, the relevant keys may be acquiredto allow service bureau 1814 to create the finished fob. As mentionedabove, step 1914 may be suitably performed by CCSS 1816 concurrently orserially with the issuance process. In one embodiment, as eachindividual fob may be being created using an issuance system suitablylocated at service bureau 1814, service bureau 1814 interrogates CCSS1816 for the appropriate cryptographic keys. These keys have either beenretrieved from key systems 1820 and 1818 earlier (i.e., after step1912), or may be retrieved in real-time in response to the request fromservice bureau 1814. Alternatively, the keys may be retrieved by CCSS1816 and transmitted to CCP 1812 prior to transmission of the fob objectto service bureau 1814. In either case, the key or keys may then beretrieved for inclusion in the fob object created in step 1908.

In step 1916, the actual fob may be issued. Service bureau 1814 maysuitably download the fob object into the correct fob hardware using thecorrect cryptographic keys. The initialized fob may then be packaged anddistributed to the appropriate fob user in accordance with conventionalmethods.

Synchronization Process

A dynamic synchronization system as described above in variousembodiments may be used to track the “state” of the consumer's fob. Thestate of the fob may be suitably characterized by the structure ofapplications used in the fob and the various pieces of data that arestored within these applications.

The manner in which applications and data are managed within a fob canvary. For example, data files and directories may be stored in a “tree”structure in fob 102. That is, the fob file structure suitably resemblesthe well-known MS-DOS (Microsoft Disk Operating System) file structurewherein files are logically organized within a hierarchy of directories.Specifically, three types of files are defined in ISO 7816-4: dedicatedfiles (DF), elementary files (EF), and a master file (MF). The masterfile may be analogous to the MS-DOS “root” directory, and contains allother files and directories. Dedicated files may actually be directoriesor “folders” for holding other DFs or EFs. Thus, the MF may contain anarbitrary number of DFs, and these DFs may or may not contain other DFs.Elementary files may be used to store user data, and may exist within adedicated file, or within the master file. Higher level DFs (i.e., DFswhich house particular applications) are often referred to asapplication dedicated files (ADFs). The scope of the present inventionis not, however, limited to this type of multi-function fob. Otherimplementations, for example, Multos or Java-based fobs, may also besuitable within the context of the instant invention.

A number of synchronization issues may arise in the multi-function fobcontext; indeed, three paradigmatic cases reoccur with some frequency,and relate to: 1) update transactions, 2) pending transactions, and 3)file structure changes. Each of these cases will now be described inturn with respect to the present invention.

Example 1 Update Transactions

It may be quite common for a fob user to make a local change to fob 102which may not be immediately reflected in all the databases which couldadvantageously make use of this information. For example, suppose thatupon initialization (i.e., when the fob was originally issued viapersonalization system 116) the fob user's fob 102 was configured toreflect a general preference for smoking (e.g., one file contains aBoolean field keyed to smoking/non-smoking), but the fob user now wishesto change this general preference file to reflect a non-smokingpreference.

In this case, referring now to FIGS. 10 and 17, and with respect to anexemplary embodiment, the fob user suitably may use fob 102 tocommunicate with a conveniently located POS device 110 via RFID reader104, whereupon authentication of the fob and/or fob-reader may takeplace (step 1702). In an exemplary embodiment, authentication may takeplace in accordance with relevant sections of the ISO 7816 standard.

Next, the fob user may use a suitable user interface (supplied by POSdevice 110 working in conjunction with server 1004) in order to performa transaction (i.e., to request a change to the preferences file) (step1704). This change may typically be reflected at the fob 102immediately. That is, POS device 110 and/or server 1004 may include thefunctionality to access and update the appropriate files within fob 102.

Communication router 1106 in server 1004 may then routes the transactionto the appropriate party (i.e., an EDSI 1008 or an EDCU 1012)corresponding to branches 1707 and 1705 respectively. That is, dependingon the system configuration, the file to be changed may be associatedwith a particular enterprise or, alternatively, may be associated withthe organization hosting the DSS. These two cases are described in turn.

Following branch 1707 in FIG. 17, the change data may be sent to andstored in the appropriate EDSI 1008 (step 1708). Update logic system1010 may then transfer this change request to the appropriate EDCU 1012(i.e., the EDCU 1012 corresponding to the particular EDSI) (step 1710).This information may be suitably stored in the corresponding updatedatabase 1404. The information may be also distributed to other EDSIs.In the instant example, update logic system 1010 may identify thosesystems that may benefit from knowing the fob user's smoking status.Such systems may include, for example, various hotels, rental caragencies, and the like.

Alternatively, following branch 1705 in FIG. 17, the data may first bestored at the appropriate EDCU (step 1712), then distributed to otherEDUCs 1012 and EDSIs 1008 as described above.

The fob data change may then be transferred to FODUS 1006. Specifically,the various fields and files associated with the fob 102 may be updatedto reflect the change stored in update database 1404. Thus, theinformation within FODUS 1006 may conform to that contained within fob102 and the various EDCUs 1012 and EDSIs 1008. After this transfer, thecorresponding change data in update database 1404 may be cleared (step1718).

Example 2 Pending Transaction

The fob user may make a change or perform a transaction through achannel that does not directly involve fob 102, thus creating aninconsistency between the data in fob 102 and the data in variousdatabases throughout the DSS. Such a case may arise, for example, whenthe fob user calls a hotel to make a reservation (rather than performingthe transaction on line using fob 102) and makes an oral request tochange his preferences from smoking to non-smoking.

Referring now to FIGS. 10 and 16, in this case, with respect to anexemplary embodiment of the present invention, the fob user first maycontact an enterprise through a means that does not include fob 102(i.e., a “fob not present” transaction) (step 1602). Using anappropriate interface (voice, keypad, etc.), a change or transaction maybe selected (step 1604). This change may then be stored locally within aparticular network 112 and/or may be stored within an EDSI 1008 (step1606).

Next, in step 1608, update logic system 1010 may route this informationto the corresponding EDCU 1012, where it resides in pending database1414. At this point, fob 102 itself may be oblivious to the change. As aresult, if the fob user were to initiate a fob-present transaction, thecorresponding enterprise may likely look first to the data structure infob 102 for preferences, and as just stated, may most likely arrive atthe wrong conclusion (e.g., a smoking room may be assignednotwithstanding the fob user's expressed preference).

In order to remedy this situation, the present invention provides, insteps 1610 and 1612, a method by which the fob may be updated upon itsnext use. That is, after fob 102 may be used to communication with POSdevice 110 via RFID reader 104 and may be suitably authenticated (step1610), the system interrogates pending database 1414 to determinewhether any changes have been made. If so, the appropriate informationmay be downloaded to fob 102 (step 1612).

After the above information transfer is successfully completed, thechange data may be transferred to FODUS 1006 (step 1614), where it maybe stored within fob object database 212. Finally, the respectiveinformation within pending database 1414 may be cleared (step 1616).

Example 3 File Structure/Application Change

In addition to the data-related modifications detailed above, changes tothe structure of data stored in fob 102 may also be desirable in certaincontexts. That is, during the life of a fob, it may be likely that thefob issuer, a partnering enterprise, or the fob user himself may desireto extend the fob's functionality by augmenting the suite ofapplications housed within the fob. For example, a fob user who may usea fob for rental car and airline reservations may also wish to use thefob for acquiring and paying for hotel reservations. In such a case, theappropriate hotel partner may process the fob user's request and arrangefor addition of a hotel application to be added to the fob filestructure. In another example, the fob issuer may authorize the additionof a new application on its own, for example, a credit and/or debitapplication. Conversely, it may also be appropriate in some instances toremove applications from the fob.

In an exemplary embodiment, the types of file structure changesdescribed above may be handled in a manner analogous to the procedureset forth in FIG. 16, depending, to some extent, upon which partyoriginates the file structure change. That is, as in step 1612, theappropriate file structure change information may be stored in EDCU 1012(for example, in database 1402), and then transferred to fob 102 whenthe fob is used in conjunction with an on-line transaction (steps 1610and 1612). After the file structure on fob 102 is augmented or otherwisemodified, FODUS 1006 (specifically, database 1016) may be similarlymodified to reflect the change. The change information may then becleared from database 1402 (step 1616).

Although the invention has been described herein in conjunction with theappended drawings, those skilled in the art will appreciate that thescope of the invention is not so limited. Modifications in theselection, design, and arrangement of the various components and stepsdiscussed herein may be made without departing from the scope of theinvention as set forth in the appended claims. For a detailedexplanation of dynamic synchronization and personalization for asmartcard, see U.S. Pat. No. 6,199,762, dated Mar. 13, 2001, titled“METHODS AND APPARATUS FOR DYNAMIC SMARTCARD SYNCHRONIZATION ANDPERSONALIZATION,” incorporated herein by reference.

Benefits, other advantages, and solutions to problems have beendescribed herein with regard to specific embodiments. However, thebenefits, advantages, solutions to problems, and any element(s) that maycause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as critical, required, or essentialfeatures or elements of any or all the claims or the invention. As usedherein, the terms “comprises,” “comprising,” or any other variationthereof, are intended to cover a non-exclusive inclusion, such that aprocess, method, article, or apparatus that comprises a list of elementsdoes not include only those elements but may include other elements notexpressly listed or inherent to such process, method, article, orapparatus. Further, no element described herein is required for thepractice of the invention unless expressly described as “essential” or“critical.”

1. A personalization system comprising: a security server having amemory and a processor; a key system associated with an application,said key system configured to communicate with said security server andto supply a key in response to a request from said security server; apersonalization utility configured to receive a data object and tocommunicate with said security server, wherein said personalizationutility is further configured to add said key to said data object; atransponder management system configured to accept a transponder requestand communicate said transponder request to said personalizationutility; and a gather application module configured to communicate withsaid transponder management system and gather application informationfrom a first database and a second database in accordance with saidtransponder request.
 2. The personalization system of claim 1, furthercomprising: a first enterprise data collection unit associated with afirst enterprise, said enterprise data collection unit configured tostore update transactions and pending transactions associated with atransponder and said first enterprise; a second enterprise datacollection unit associated with a second enterprise, said secondenterprise data collection unit configured to store update transactionsand pending transactions associated with said transponder and saidsecond enterprise; and wherein said first database is associated withsaid first enterprise, and said second database is associated with saidsecond enterprise.
 3. The system of claim 1, wherein said transpondermanagement system is further configured to parse said transponderrequest in order to choose optimum transponder characteristics.
 4. Thesystem of claim 1, wherein said personalization utility is furtherconfigured to facilitate formatting said data object.
 5. The system ofclaim 1, further comprising an activation block configured to facilitateactivation of said transponder.
 6. The system of claim 1, wherein saidgathering application module is further configured to gather from saidfirst database and said second database in accordance with saidtransponder request which further comprises creating at least one of afile structure, data set and data type.
 7. The system of claim 1,wherein said transponder management system is further configured toissue said transponder corresponding to said transponder request.
 8. Thesystem of claim 1, further comprising an object database system thatstores said transponder information based, at least in part, on at leastone of said update transactions and said pending transactions, whereinsaid transponder information includes a data object having anapplication, and wherein said object database system is communicativelycoupled to said first and second enterprise data collection units. 9.The system of claim 1, further comprising an update logic system havinga processor that routes said transponder information from said first andsecond enterprise data collection units to a point-of-sale device inorder to effect synchronization of said transponder informationassociated with said transponder and said object database system,wherein said point-of-sale device includes a transponder-readercommunicatively coupled with said transponder and said first and secondenterprise data collection units.
 10. The system of claim 1, furthercomprising an update logic system coupled to an enterprise datasynchronization interface, said update logic system configured tosecurely route transponder information between said enterprise datasynchronization interface and said enterprise data collection units,said enterprise data synchronization interface coupled to an enterprisenetwork configured to communicate with said point-of-sale device. 11.The system of claim 10, further comprising a secure support clientserver configured to communicate with said point-of-sale device, saidsecure support client server further configured to adaptively providecommunication functionality in accordance with the communicationfunctionality available at said point-of-sale device.